somewhere to talk about random ideas and projects like everyone else

stuff

#internet exploder

VectorEditor on Wave 12 August 2009

So I don’t actually have wave yet, but for all 2 of you (likely less) who have used pygowave, an open source third party implementation of the wave protocol. So there was how I developed it, I read through the APIs and tested on pygowave. So what does VectorEditor do that svg-edit and… erm… svg-edit don’t do?

First, VectorEditor for wave is really really real time. Waaay more real time than svg-edit (not really). But VectorEdit (VectorWave might be a nice name.. I’m going to try using that name from now on in this post) transmits the data such as even while the shape is still being drawn, rotated, or moved (rotation needs work). Another nice feature is that the transitions are animated so things are even more seamless.

Another important feature is shape locking. So when someone selects a shape, it gets locked and can’t be edited by anyone else. If anyone tries, an alert box appears saying “Shape shape:5sdfwef98dfe3ssdf is locked by user antimatter15@pygowave.p2k-network.org”. svg-edit (the latter) doesn’t support moving things after they’re created so it doesn’t really matter then, and I’m quite certain the former doesn’t do any type of locking.

And lets not forget the likely most important, yet totally untested feature that seperates VectorEditor from the rest: IE support, which is inherent since it uses Raphael for rendering, but it may not be necessary since google may be making some shim-type system of hacking svg awesomeness onto IE and making the whole VectorEditor project useless.

So if you want to try it out, go to pygowave, sign up, create a wave and add the


Crashing IE 20 December 2008

Well, I was trying to iron out a IE bug for project wikify. Interestingly, that bug I encountered, crashes every IE since 5.5 (not sure if it crashes 5.0 yet, browsershots are still loading)

http://wikify.googlecode.com/svn/trunk/v2/crashie.htm

really, this just is just another IE issue….


Ajax Animator Thoughts 25 October 2008

I’ve set some tiny goals for Ajax Animator 0.21/0.22/0.23/0.24/0.25. I’m not really good with version numbers.

0.21 is mostly to work on the collaborative, online, web 2.0 aspect of it. Enabling collaboration is important, and I’m a huge supporter of User Created content (virtually all my projects are open source, and they include some entirely user-created things like my MMORPG, Project Wikify, and a few others). At one point, since the old ajax animator (not anymore) would keep logs of everything previewed (as we needed to convert it to flash to preview). I would enjoy people trying out how things were like. That was in the day where there were to tools: rectangles and sticks, and the lines didn’t tween well. Color picking was unnecessarily complicated, the tweening engine crashed every minute, and couldn’t do anything, etc. Since the 0.2 rewrite, things are much better, but I still miss having those user-management features.

If you didn’t know that, User Management/Sharing has been in the ajax animator for a while. It was frequently added, removed, mutilated, upgraded, etc. I think it was there since the DHTML Goodies days (0.08?). It got removed for a while, got added again, removed, rewritten, and now removed again. I look forward to adding it again.

I guess much of it is already there. The login should look pretty much the same as the old one, but with the whole login thing replaced with a single OpenID box and a login button. I’m not exactly sure what to do after this. I think there should be a little profile box that replaces the login panel. I’m debating whether the profile should house a list of your saved animations, or if it should be nested into that Animation browser (that actually works!). I’m leaning towards the latter. The profile may house a link to your folder in the animation directory, a button to save your edits (as with File->Save->Webserver). Etc.

With that, it would include some form of user management system. I’ve almost completely settled on OpenID because of it’s flexibility, futuristicity, freaking-awesomeness (getting a bit overboard…). I’ve just been surfing the web (Wikipedia stuff) and I’m increasingly interested in OpenID, as it seems much more “ajax-friendly” than I previously thought.

Some time, i’d like to switch to a more scalable app-engine oriented system (it’s already serving up static JS now). I’ll use my server at antimatter15.com more (Java-Enabled), so there can finally be decent flash export :)

One thing that i’d really like, that’s really probably painful, is to better support IE. There’s no problem with IE support in the general components of the Ajax Animator (Tweening/UI/Save/Format/Abstraction Layer/etc), but rendering isn’t very good. I’d like for it to be better. OnlyPaths is already great, but IE support is big for it to become mainstream. I’d like it for use in a more educational and amature(ish) setting, where people have the most use for free/opensource/easy-to-run apps. In education, many people are still using IE, and that’s a big problem.

I’ve been looking into other renderers for the future of the Ajax Animator to run on. For the forseeable future, the editor will be OnlyPaths, because it is the only one that really fits the needs of the project. But it’s built on a less-clean, prototype-like (non-namespaced) foundation, and isn’t built exactly as it should. It’s not up to me, but I think that OnlyPaths should be an editor, rather than a renderer, or at least the renderer and the editor to have very visible lines between. Right now, much of the editor interface is in the renderer. That means a lot of unnecesary work. The addTracker function is currently in the renderer, this is completely the wrong thing. It was fine in the days when it was Richdraw and the tracker was just a blue square, but that’s not scalable. On this trend, you would need 2 copies of essentially the same code (VML/SVG) for the tracker/etc. I’d much prefer to have a interactive-less renderer and addTracker function in the editor, where all the actions are calls to the drawing API. Either Onlypaths has to get a better VML renderer, or we have to switch rendering engines to something like Dojo.GFX or Raphael and port the editor over to the new renderers. I like the current OnlyPaths one a lot. It’s been developed side-by-side with the Ajax Animator, and is very well integrated. I dont like Dojo.GFX too much, because it’s dojo-dependencies, but it’s a very solid and stable framework. And Raphael isn’t as powerful as the current OnlyPaths engine yet.


IE works in development version 06 August 2008

I made a mistake in the ads script that made IE unhappy (along with some other stuff). IE works in the development unstable version, which will be merged into the stable as 0.20 Beta RC2 (Aka 0.20.01)

As you can see, I’m not familiar with software versioning….



Ajax Animator 0.20.01 Soon 05 August 2008

I’m going to release 0.20.01 soon, which will get IE to load properly, and fix some general bugs.


new IE not supported error 29 July 2008

This time I think my tone is a bit more acceptable (no more “Error: YOUR BROWSER SUCKS!” stuff)

Currently, support for Microsoft Internet Explorer (6/7/8) are only experimental. 
Some features do not work properly such as animation and playback of some specific animations. 
The issues are being resolved, but in the mean time, you may try out another browser such as 
<a href='http://getfirefox.com'>Firefox</a>, 
<a href='http://opera.com'>Opera</a>, or 
<a href='http://apple.com/safari'>Safari</a>.

IE somewhat works 29 July 2008

I just discovered the source of virtually all the IE problems: the non functional VMLRENDERER.prototype.info() function. I managed to implement part of it, and magically, IE works a bit. Its nto very stable, and the tween engine gets weird errors all the time.


New Features 29 September 2007

I’m just doing some size reduction, and ui improvement now. There has been some preliminary support for IE, and also a rewrite of the tweening engine to support lines.